home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / rfc / rfcxxxx / rfc1371 < prev    next >
Text File  |  1995-07-25  |  18KB  |  508 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                  P. Gross, Editor
  8. Request for Comments: 1371                              IETF/IESG Chair
  9.                                                            October 1992
  10.  
  11.  
  12.               Choosing a "Common IGP" for the IP Internet
  13.                  (The IESG's Recommendation to the IAB)
  14.  
  15. Status of this Memo
  16.  
  17.    This memo provides information for the Internet community.  It does
  18.    not specify an Internet standard.  Distribution of this memo is
  19.    unlimited.
  20.  
  21. Special Note
  22.  
  23.    This document was originally prepared as an Internet Engineering
  24.    Steering Group (IESG) recommendation to the Internet Architecture
  25.    Board (IAB) in mid-summer 1991, reaching the current version by the
  26.    date shown above.  Although the document is now somewhat dated (e.g.,
  27.    CIDR and RIP II are not mentioned), the IESG felt it was important to
  28.    publish this along with the recent OSPF Applicability Statement [11]
  29.    to help establish context and motivation.
  30.  
  31. Abstract
  32.  
  33.    This memo presents motivation, rationale and other surrounding
  34.    background information leading to the IESG's recommendation to the
  35.    IAB for a single "common IGP" for the IP portions of the Internet.
  36.  
  37.    In this memo, the term "common IGP" is defined, the need for a common
  38.    IGP is explained, the relation of this issue to other ongoing
  39.    Internet Engineering Task Force (IETF) routing protocol development
  40.    is provided, and the relation of this issue to the goal for multi-
  41.    protocol integration in the Internet is explored.
  42.  
  43.    Finally, a specific IGP is recommended as the "common IGP" for IP
  44.    portions of the Internet -- the Open Shortest Path First (OSPF)
  45.    routing protocol.
  46.  
  47.    The goal of this recommendation is for all vendors of Internet IP
  48.    routers to make OSPF available as one of the IGP's provided with
  49.    their routers.
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. IESG                                                            [Page 1]
  59.  
  60. RFC 1371                Choosing a "Common IGP"             October 1992
  61.  
  62.  
  63. Table of Contents
  64.  
  65.    1. Background ....................................................  2
  66.    2. Multiple Internet Standard Routing Protocols Possible .........  3
  67.    3. A Common IGP ..................................................  3
  68.    4. Impact of Multi-protocol Topology and Integrated IP/CLNP Routing 3
  69.    5. Commitment to Both IP and CLNP ................................  5
  70.    6. Some History ..................................................  5
  71.    7. IESG Recommendations ..........................................  6
  72.    7.1 Regarding the Common IGP for the IP Internet .................  6
  73.    7.2 Regarding Integrated IP/CLNP Routing .........................  7
  74.    7.3 Limits of the Common IGP Recommendation ......................  7
  75.    8. References ....................................................  8
  76.    9. Security Considerations .......................................  9
  77.    10. Author's Address .............................................  9
  78.  
  79. 1. Background
  80.  
  81.    There is a pressing need for a high functionality non-proprietary
  82.    "common" Interior Gateway Protocol (IGP) for the TCP/IP protocol
  83.    family.  An IGP is the routing protocol used within a single
  84.    administrative domain (commonly referred to as an "Autonomous System"
  85.    (AS).
  86.  
  87.    By "common", we simply mean a protocol that is ubiquitously available
  88.    from all router vendors (as in "in common").  Users and network
  89.    operators have expressed a strong need for routers from different
  90.    vendors to have the capablity to interoperate within an AS through
  91.    use of a common IGP.
  92.  
  93.    Note:  Routing between AS's is handled by a different type of routing
  94.    protocol, called an "Exterior Gateway Protocol" ("an EGP", of which
  95.    the Border Gateway Protocol [2] and "The Exterior Gateway Protocol"
  96.    [3] are examples.)  The issues of routing between AS's using "an" EGP
  97.    is not considered in this memo.
  98.  
  99.    There are two IGPs in the Internet standards track capable of routing
  100.    IP traffic -- Open Shortest Path First (OSPF) [4] and Integrated IS-
  101.    IS [5] (based on the OSI IS-IS). These two protocols are both modern
  102.    "link state" routing protocols, based on the Dijkstra algorithm.
  103.    There has been substantial interaction and cooperation among the
  104.    engineers involved in each effort, and the protocols share some
  105.    similar features.
  106.  
  107.    However, there are a number of technical design differences.  Most
  108.    noteably, OSPF has been designed solely for support of the Internet
  109.    Protocol (IP), while Integrated IS-IS has been designed to support
  110.    both IP and the OSI Connectionless Network Layer Protocol (CLNP)
  111.  
  112.  
  113.  
  114. IESG                                                            [Page 2]
  115.  
  116. RFC 1371                Choosing a "Common IGP"             October 1992
  117.  
  118.  
  119.    simultaneously.
  120.  
  121. 2. Multiple Internet Standard Routing Protocols Possible
  122.  
  123.    The Internet architecture makes a distinction between "Interior
  124.    Gateway Protocols (IGPs)" and "Exterior Gateway Protocols (EGPs)".
  125.    IGPs are routing protocols used within an Autonomous System (AS), and
  126.    EGPs are routing protocols used between different AS's.
  127.  
  128.    Therefore, the Internet architecture supports the use and
  129.    standardization of multiple IGP routing protocols.  For example, it
  130.    is perfectly reasonable for one standard routing protocol to be used
  131.    within one AS; while a second standard routing protocol is used
  132.    within a second AS; at the same time that a non-standard proprietary
  133.    routing protocol is used within a third AS.
  134.  
  135.    The primary purpose for making standards is to allow
  136.    interoperability.  Setting a protocol standard in the Internet says,
  137.    in effect, "if you wish to use this protocol, you should do it as
  138.    specified in the standard so that you can interoperate with others
  139.    who also wish to use this protocol."  It is important to understand
  140.    that simply specifying a standard does not, by itself, designate a
  141.    requirement to use the standard.  It is merely meant to allow
  142.    interoperability among those who choose to follow the standard.
  143.  
  144.    Therefore, it is reasonable for both OSPF and Integrated IS-IS to be
  145.    progressed through the Internet Standards process as appropriate
  146.    (based on the criteria specified in [6]).  In addition, it is
  147.    possible that other IGPs may be developed and standardized in the
  148.    future.
  149.  
  150. 3. A Common IGP
  151.  
  152.    Although the Internet architecture allows for multiple standard IGP
  153.    routing protocols, interoperability of router products from different
  154.    vendors within a single AS would be greatly facilitated if a single
  155.    "common" IGP were available from all router vendors.  Designating a
  156.    single common IGP would have the goal of enabling multi-vendor router
  157.    interoperation with a modern high functionality routing protocol.
  158.  
  159.    However, designating a common IGP does not mandate the use of that
  160.    IGP, nor would it be meant to discourage the use of other IGPs in
  161.    situations where there may be sound technical reasons to do so.
  162.  
  163. 4. Impact of Multi-protocol Topology and Integrated IP/CLNP Routing
  164.  
  165.    There are topology considerations which will affect the designation
  166.    of a "common" Internet IGP.
  167.  
  168.  
  169.  
  170. IESG                                                            [Page 3]
  171.  
  172. RFC 1371                Choosing a "Common IGP"             October 1992
  173.  
  174.  
  175.    The Internet requires support for a wide variety of protocol suites.
  176.    If we consider only IP and OSI CLNP, then the Internet is expected to
  177.    contain:
  178.  
  179.    1. Pure IP AS's (in which IP is used but OSI CLNP is not used);
  180.  
  181.    2. Pure CLNP AS's (in which CLNP is used but IP is not used);
  182.  
  183.    3. Dual IP/CLNP ASs, with a common topology (i.e., all links and
  184.       routers in the AS support IP and CLNP, and a single common
  185.       topology is used for both protocol suites);
  186.  
  187.    4. Dual, overlapping IP/CLNP ASs with differing topologies (i.e.,
  188.       some links are dual, while some are IP-only and some are
  189.       CLNP-only, resulting in different topologies for IP routing and
  190.       CLNP routing).
  191.  
  192.    For (1), (i.e., a pure IP environment) any IGP capable of routing IP
  193.    traffic could be used (e.g., OSPF or Integrated IS-IS).
  194.  
  195.    For (2), (i.e., a pure CLNP environment) any IGP capable of routing
  196.    CLNP traffic could be used (e.g., OSI IS-IS or Integrated IS-IS).
  197.  
  198.    For (3), (i.e., routing environments in which both IP and CLNP are
  199.    present in a common topology) there are two possibilities for managing
  200.    routing:
  201.  
  202.    1. Separate routing protocols could be used for each supported
  203.       protocol suite.  For example, OSPF may be used for calculating
  204.       routes for IP traffic and OSI IS-IS may be used for calculating
  205.       routes for OSI traffic.  Or Integrated IS-IS could be used for
  206.       calculating routes for IP traffic and OSI IS-IS could be used
  207.       for calculating routes for CLNP traffic.
  208.  
  209.       This approach of using separate routing protocols and management
  210.       for each supported protocol family has come to be known as "Ships
  211.       in the Night" because the two routing protocols share the
  212.       hardware/software resources of the router without ever actually
  213.       interacting on a protocol level.
  214.  
  215.    2. "Integrated routing" could be used, in which a single routing
  216.       protocol is used for both IP and CLNP.  At this time, Integrated
  217.       IS-IS is the only choice for "integrated routing".
  218.  
  219.    For (4), (i.e., routing environments in which both IP and CLNP are
  220.    present but in an overlapping different topology) separate routing
  221.    protocols are required for the IP and CLNP environments (i.e., "Ships
  222.    in the Night").  This is equivalent to two separates cases of (1) and
  223.  
  224.  
  225.  
  226. IESG                                                            [Page 4]
  227.  
  228. RFC 1371                Choosing a "Common IGP"             October 1992
  229.  
  230.  
  231.    (2), but it is pointed out here as a separate case for completeness.
  232.  
  233. 5. Commitment to both IP and CLNP
  234.  
  235.    The IAB/IETF are committed to a timely introduction of OSI into the
  236.    Internet.  In recognition of this commitment, the IETF has an entire
  237.    area devoted to OSI integration.
  238.  
  239.    However, while this introduction is taking place, it is essential
  240.    that existing services based on IP be continued.  Furthermore, IESG
  241.    also feels that even after more widespread introduction of CLNP, IP
  242.    and CLNP will continue to coexist in the Internet for quite some
  243.    time.  This view is consistent with the IAB goal of a multi-protocol
  244.    Internet.
  245.  
  246.    Therefore, the IESG has a strong commitment to the continued support
  247.    for IP throughout the Internet.  Maintenance of this IP support
  248.    requires selection of a common IGP suitable for support of IP, and
  249.    requires that this selection be based on operational experience.
  250.  
  251. 6. Some History
  252.  
  253.    In February 1990, the IESG recommended that the question of
  254.    designating a "common" IGP be postponed until more information was
  255.    available from each protocol.  More than a year has now passed since
  256.    the IESG's recommendation.  There have been significant advancements
  257.    in specification, implementation, and operational experience with
  258.    each protocol.  It is now reasonable to re-open the consideration of
  259.    designating a "common IGP".
  260.  
  261.    At the March 1991 meeting of the IETF, the IETF Routing Area Director
  262.    presented a set of criteria for the advancement of routing protocols
  263.    through the Internet standards process [6].  More information
  264.    regarding the IAB Internet Standards process can be found in [1].
  265.  
  266.    Also, at the March 1991 meeting of the IETF, the OSPF Working Group
  267.    requested that OSPF be considered for advancement to Draft Internet
  268.    Standard.  The OSPF WG submitted four documents to the IETF to
  269.    support its request:
  270.  
  271.    o a revised protocol specification to update [4];
  272.  
  273.    o an SNMP Management Information Base (MIB);
  274.  
  275.    o two technical reports giving a technical analysis and operational
  276.      experience with OSPF.  These reports follow the format recommended
  277.      in [6].
  278.  
  279.  
  280.  
  281.  
  282. IESG                                                            [Page 5]
  283.  
  284. RFC 1371                Choosing a "Common IGP"             October 1992
  285.  
  286.  
  287.    These four documents have now been published as [7, 8, 9, 10]
  288.    respectively.
  289.  
  290.    In summary for OSPF:
  291.  
  292.    o all features of OSPF have tested (although not all features have
  293.      been used in operation),
  294.  
  295.    o OSPF has been shown to operate well in several operational
  296.      networks containing between 10 and 30 routers,
  297.  
  298.    o interoperation among routers from multiple vendors has been
  299.      demonstrated at organized "bakeoffs".
  300.  
  301.    In May 1991, the IAB approved the IETF/IESG recommendation to advance
  302.    OSPF to Draft Internet Standard.
  303.  
  304.    Integrated IS-IS, as specified in [5], is currently a Proposed
  305.    Internet Standard.  In July 1991, the status of Integrated IS-IS is
  306.    as follows:
  307.  
  308.    o There are several separate implementations of integrated
  309.      IS-IS under development,
  310.  
  311.    o Integrated IS-IS has worked well in several multi-area operational
  312.      networks, one containing between 20 and 30 routers,
  313.  
  314.    o These recent operational results have not yet been fully
  315.      documented.  Documentation, showing satisfaction of the criteria
  316.      given in [6] for advancing routing protocols, will be submitted
  317.      to the IESG when Integrated IS-IS is submitted for Draft Internet
  318.      Standard status.
  319.  
  320. 7. IESG Recommendations
  321.  
  322. 7.1 Regarding the Common IGP for the IP Internet
  323.  
  324.    Based on the available operational experience and the pressing need
  325.    for a high functionality IGP for the IP protocol family, the IESG
  326.    recommends that OSPF be designated as the common IGP for the IP
  327.    portions of the Internet.  To help ensure that this IGP is available
  328.    to all users, the IESG recommends that the IETF Router Requirements
  329.    Working Group specify OSPF as "MUST IMPLEMENT" in the document
  330.    "Requirements for Internet IP Routers".
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. IESG                                                            [Page 6]
  339.  
  340. RFC 1371                Choosing a "Common IGP"             October 1992
  341.  
  342.  
  343. 7.2 Regarding Integrated Routing
  344.  
  345.    As mentioned above, the IESG is commited to multiprotocol
  346.    environments, and expects usage of OSI CLNP to increase in the
  347.    Internet over time.
  348.  
  349.    However, at this time, the IESG is not prepared to take a position
  350.    regarding the preference of either "Ships in the Night" or Integrated
  351.    routing for such mixed routing environments.  At this time, the
  352.    "Ships in the Night" approach is most widely used in the Internet.
  353.    Integrated routing has the potential advantage of reducing resource
  354.    utilization.  However, additional operational experience is needed
  355.    before any potential advantages can be fully evaluated.
  356.  
  357.    Therefore, the IESG wishes to encourage implementation of Integrated
  358.    IS-IS so that a reasonable position can be determined based on
  359.    operational experience.  All implementers of Integrated IS-IS are
  360.    encouraged to coordinate their activity with the IETF IS-IS Working
  361.    Group, which is actively collecting information on such experience.
  362.  
  363. 7.3 Limits of the Recommendation
  364.  
  365.    It is useful to recognize the limits of this recommendation.  This
  366.    recommendation does not take a position on any of the following
  367.    issues:
  368.  
  369.    1. What IGP (if any) users should run inside an AS. Users are free to
  370.       run any IGP they wish inside an AS.
  371.  
  372.    2. What IGP is technically superior, or has greater operational
  373.       utility.
  374.  
  375.    3. What IGP any vendor should recommend to its users for any specific
  376.       environment.
  377.  
  378.    4. What IGP should be used within a CLNP-only environment.
  379.  
  380.    Again, this recommendation is meant to designate one modern high
  381.    functionality IGP that should be implemented by all vendors of
  382.    routers for the IP portion of the Internet.  This will enable routers
  383.    from vendors who follow this recommendation to interoperate within a
  384.    single IP Autonomous System.
  385.  
  386.    It is not our intent to discourage the use of other routing protocols
  387.    in situations where there may be sound technical reasons to do so.
  388.    Therefore, developers of Internet routers are free to implement, and
  389.    network operators are free to use, other Internet standard routing
  390.    protocols, or proprietary non-Internet-standard routing protocols, as
  391.  
  392.  
  393.  
  394. IESG                                                            [Page 7]
  395.  
  396. RFC 1371                Choosing a "Common IGP"             October 1992
  397.  
  398.  
  399.    they wish.
  400.  
  401. 8.  References
  402.  
  403.    [1] Internet Activities Board, "The Internet Standards Process", RFC
  404.        1310, IAB, March 1992.
  405.  
  406.    [2] Lougheed, K., and Y. Rekhter, "A Border Gateway Protocol 3 (BGP-
  407.        3)", RFC 1267, cisco Systems, T.J. Watson Research Center, IBM
  408.        Corp., October 1991.
  409.  
  410.    [3] Mills, D., "Exterior Gateway Protocol Formal Specification", STD
  411.        18, RFC 904, UDEL, April 1984.
  412.  
  413.    [4] Moy, J., "OSPF Specification", RFC 1131 (Superceded by [7]),
  414.        Proteon, October 1989.
  415.  
  416.    [5] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual
  417.        Environments", RFC 1195, DEC, December 1990.
  418.  
  419.    [6] Hinden, R., "Criteria for Standardizing Internet Routing
  420.        Protocols", RFC 1264, BBN, October 1991.
  421.  
  422.    [7] Moy, J., "OSPF Version 2", RFC 1247, Proteon, July 1991.
  423.  
  424.    [8] Baker, F., and R. Coltun, "OSPF Version 2 Management Information
  425.        Base", RFC 1253, ACC, Computer Science Center, August 1991.
  426.  
  427.    [9] Moy, J., "Experience with the OSPF Protocol", RFC 1246, Proteon,
  428.        July 1991.
  429.  
  430.   [10] Moy, J., "OSPF Protocol Analysis", RFC 1245, Proteon, July 1991.
  431.  
  432.   [11] Internet Architecture Board, "Applicability Statement for OSPF",
  433.        RFC 1370, IAB, October 1992.
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. IESG                                                            [Page 8]
  451.  
  452. RFC 1371                Choosing a "Common IGP"             October 1992
  453.  
  454.  
  455. 9. Security Considerations
  456.  
  457.    Security issues are not discussed in this memo.
  458.  
  459. 10. Author's Address
  460.  
  461.    Phillip Gross, IESG Chair
  462.    Advanced Network & Services
  463.    100 Clearbrook Road
  464.    Elmsford, NY
  465.  
  466.    Phone: 914-789-5300
  467.    EMail: pgross@ans.net
  468.  
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.  
  477.  
  478.  
  479.  
  480.  
  481.  
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. IESG                                                            [Page 9]
  507.  
  508.